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ABSTRACT 

Dynamic discussions have begun to emerge concerning 
style of presentation on world wide web sites. Some hypertext markup 
language (HTML) designers seek an intimate and chatty ambience, while 
others want to project a more professional image. Evaluators see many 
sites as overdecorated and indecipherable. This paper offers 
suggestions on selecting projects and design types appropriate to 
HTML and also on maximizing clarity and navigability while creating 
hyperlinks and displaying text. The incorporation of images, and even 
short movies, is becoming increasingly popular, but often such files 
are too large to be manageable or practical. The designer can reduce 
the size of the image or movie window, reduce the bit depth of the 
colors, or reduce the number of frames per second of moving images. 
Studies were conducted to investigate how altering images in these 
ways influence loading time, file size, and perceived quality. Six 
figures, including reproductions of computer screens, and two tables 
illustrate the discussion. An appendix provides uniform resource 
locators (URLs) for 46 clip art and icon collections on the world 
wide web, (BEW) 
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Designing Multimedia for HTML 

The World Wide Web invites anyone to publish sophisticated thought or 
unimaginable palaver without discrimination. Despite the opaque nature of HTML 
(HyperText Markup Language), and the limitations of most computers and their lines 
to handle large amounts of data efficiently, vast amounts of information are being 
added to the Web daily. Multimedia resources, and especially learning resources, 
make up a large portion of what is available on the wo.b; some are well designed while 
others are not. 

Designing an HTML page is both a technical and artistic challenge. Some of the 
technical issues are dealt with in a companion paper (Misanchuk and Schwier, 1996). 
We’re coming to the opinion that design and good taste, while perhaps overblown 
and over-sold as important to learning, aren’t entirely intuitive. Elizabeth Boling 
commented that when some people design their first web pages, “they seem to 
gravitate to (embrace?) the most vulgar forms— blinking text, egregious menu bars, 
decorative graphics, indecipherable icons” (personal communication, December 2, 
1995). Our experience has been similar. Without any coaching beyond the technical 
"press this key, then that one" variety, we turned a group of students loose on 
designing a web page. The task was to introduce themselves to the educational 
technology community in Canada with a brief textual description and a photo. Well, 
you can probably imagine what happened— blinking text, headings and subheadings 
by Freddie Krueger, and writing styles that ranged from point form lists of 
accomplishments to cute and disarming stories about pets and children. We found the 
differences in writing styles were very interesting. There were very different 
assumptions about what material on the web "should" look like. Some (we suspect the 
ones who have a great deal of casual web experience) seemed to think that the 
material should be personal, intimate, casual and chatty. Others wanted to project a 
professional image, and thought the casual material was trivial. What has emerged 
froia the experience is a very dynamic discussion of "style of presentation" on the 
web. 

A host of design considerations obtain once a designer has elected to publish a 
multimedia document using HTML. This paper considers several design 
considerations in turn, the first of which is how to select appropriate projects for 
HTML production. 

Selecting HTML Projects 

Currently, the majority of connections to the World Wide Web are too slow to 
adequately display the full range of multimedia options. Most modems operate at 
14,400 bps, with newer technology operating at 28,800 bps. This is woefully 
inadequate for loading large graphics, movies, and sound files to the user. For 
example, the promotional copy for the Mac&Fax Sportster fax/ data modem boasts that 
the modem “Speeds graphics files to service bureaus — a 2MB graphic file that takes 2.5 
hours at 2400 bps takes only 23 minutes with the Sportster 14,400 Mac&Fax” (U.S. 
Robotics, 1995). Considering that most learners will not wait 23 seconds, let alone 23 
minutes, for a graphic to appear on the screen, the advertising copy argues 
forcefully against using a great deal of multimedia when designing for the web. Even 
ethernet connections can be slow at times. So the first guideline for selecting HTML 
multimedia projects is; 

think, and then think small. 




3 



V 



Designing Multimedia for HTML 



3 



Designers also need to consider that the end-user has a great deal of control over the 
features of a document— margins, background colours, text size and font. This 
requires designers to design robust documents which can survive choices and 
indignities imposed by users— the instructional design equivalent of child-proofing 
your home. This leads to the second guideline for selecting HTML projects: 

select designs the learner can influence. 

Interaction, especially interaction of the “point and click” variety, is possible with 
HTML. But answer judging isn’t necessarily easy to accomplish. Linking, of course, is 
its strongest feature, and a healthy amount of interaction is possible by allowing 
learners to trace unique paths through information. Other types of interaction are 
better left to authoring systems designed for that type of production. HTML’s 
strength is organizing information systems, so a third selection guideline is: 

give preference to information-based projects. 



File Management 

HTML usually requires the designer to link several documents, and this can 
influence the execution and appearance of a project. Home pages should be small, 
without elaborate or unnecessary graphics. This allows users to load the files quickly. 

Few things are as annoying (and sometimes expensive) for users than to wait a long 
time to load a home page, only to discover that the information at the site is not what 
was wanted in the first place. 

In HTML documents, it is conventional to identify head, title and body elements 
(<head>, </head>, <title>, </title>, <body>, </body>). Why? These tags facilitate searching 
and indexing. As searching engines for the web continue to evolve, these labelling 
conventions will help confine searches to the fields identified for the search, and 
make searching much more efficient. Titles should be as short as possible to further 
facilitate searching. 

Add contact information to the home page. As a courtesy to users of any web site, it is 
conventional to include a method of contacting the author, perhaps with an e-mail 
address or phone number. It is simple enough to automate a mail function. 

It is conventional to embed links naturally within prose unless there are many of 
them, in which case “bulleted” lists are preferable. This convention is probably an 
aesthetic, rather than an effectiveness concern, but we know of no specific research 
on this topic. Still, it is probably good advice to keep links as unobtrusive as possible, 
yet apparent to the user. Embedded links are less likely to break up the flow of a 
document for the reader. 

A good research problem is to examine the effectiveness of long/short links and 
multiple links. To our knowledge, nobody has yet investigated user preference or the 
effectiveness of different linking strategies. 

It is generally a good idea to build links to other documents, rather than to locations 
within a single, large document. For example, a list of links can each be tied to an 
external file, and that file can provide a link back to the “jumping-off’ position lu 
the original document. This provides easy navigation back and forth. By contrast, 
consider a large document in which links are ed to different positions in the body 
of the document. Once you jump from one place to another in the document, how do 
you build the link to the next place in the document? Awkwardly. It is difficult to 
include “return to point of departure” links in the document when each destination 
may have originated from several different location. Most users will survive by 
using the “back” button in browsers such as Netscape, but this is an awkward 
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solution at best, and outside the control of the instructional designer. Another 
advantage of lin.dng several smaller documents is improved execution time. A large 
document will require a long time to load, and this is an inefficient use of connection 
time if the user is going to look at only a small subset of the information on the page. 

Text Display and Layout 

The layout of information includes the position of text and images, the use of tables to 
establish columns of information, the production of lists and preformatted text, and 
the incorporation of external images, sounds and animation. A well-designed project 
layout considers both the design of a particular page and the layout of several 
logically related documents. 

Textual display, while significandy under the control of the user, can still be 
manipulated by the designer. At the very least, recommendations can be given to the 
user on how to set up the display if the textual design is critical. It is important to 
remember that despite the unique and sometimes frustrating nature of writing in 
HTML, age-old principles of good document design should be observed. Probably most 
importantly, documents should have a consistent presentation style. 

HTML layout commands are divided into two types: logical and physical elements. 

Logical elements are tags which define which design elements are placed on the 
screen, but leave the decisions about how they look up to the user. For example, a 
logical element tag is <EM> </EM> which stands for emphasis and <STRONG> </STRONG> 
stands for strong emphasis. Depending on the choices made by the learner, the 
browser may display emphasized text as italics, or red, or underlined. 

Physical elements, on the other hand, try to wrest control of th<j design from the 
user, and impose very specific limits on the design. For example <1> </l> stands for 
italics and <B> </B> stands for bold-facing, and these will be imposed on text, 
regardless of the wishes of the user. These are also subject to the limitations of any 
particular browser to display the physical elements imposed. 

You will find that most resources argue in favour of using logical elements, and 
giving the design control over to the user. As desirable as this might be in most cases, 
it challenges designers to anticipate the mess learners can make of materials. 

Another thing to remember whe i laying out text is that layout tags don’t necessarily 
operate the way one might predict. For example, the paragraph tag <p> marks a 
container for text— not a space insertion as in word processing. HTML recognizes 
only the largest spacing value of a logical structure element (e.g., <p>, <br>) will be 
used. This means that an HTML document displays command structure <p> <p> <p> <p> 
the same as <p> in most browsers. 

The <PRE> element is used in HTML to force text into columns or other alignments. 

Space text with the space bar (not with tabs, etc.). This is the only way to display 
tabular data with HTML 2.0. 

A simple strategy for developing elaborate designs is to copy source code for an 
appealing design or strategy, and manipulate it to fit your material. This can save 
time, but can also constrain the designer to the limits imposed by the original, and 
more skilled, programmer. 

Image Use and Display 

Images can be stored in only a few formats if they are to be used within docuni'^iits. 
Images can be in one of three formats: 
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.gif GIF format file 

.xbm X-Bitmap (black and white) 

.xpm X-Pixelmap (colour) 

Other formats such as JPEG are possib .e to use, but require helper applications to be 
displayed (see Misanchuk and Schwier, 1996 for an explanation of helper 
applications). 

Icon archive sites are plentiful on the internet. We conducted a simple search on 
January 7, 1996 using keywords “clip art” and “icon”. The URLs in Appendix 1 were 
the rirst 46 “hits” in a list of 100. We make no claims as to their usefulness or their 
content, but list them as a jumping-off point for you if you are looking for clip art 
and image collections for your own projects. The content ranges from business icons 
to wedding art. Publications also include sites for locating icons and artwork (e.g., 
Graham, 1995), but we suggest you also conduct your own searches on the WWW, 
because sites and URLs are very volatile, and often change before print documents 
can reach publication. 

A particularly attractive, and perhaps effective, navigation strategy is to employ 
“clickable” pictures. These can be accomplished in on-line HTML applications, but 
not necessarily easily. A companion program is required to map transparent buttons 
onto the pictures. The actual procedure for producing imagemaps can be daunting, 
but Frost (1996) provides a very useful, step-by-step description of hov/ to script an 
imagemap for beginners. Active images <IMAGEMAPS> also require an HTML program 
to access a gateway program active on the system (Frost, 1996; Graham, 1995). It 
appears that this mitigates against using CD-ROM as a medium for using imagemaps. A 
related, if not quite as elegant solution is to produce a “button bar” or series of small 
thumbnail images in a line, each of which acts as a separate navigation button (see 
Figure 1). This is somewhat easier to accomplish and it doesn’t require the active 
gateway program to operate. For specific advice and examples of how to script a 
button bar, a good resource is provided by the Stanford Computer Science Department 
at: 



http://www'-pcd.stanford.edu/gifs/buttonbars.html 



Figure 1. Example of button bar from Stanford Computer Science Department. 
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<! — Include file — > 

<! — Icon her for CS dept, ?CH group — > 

<K KREFm " http : //ir^rr.stenf ord.edu/ “ > 

<ltJ& SB.Cs" /gifs /stenfcrd.seelSS. gif'* ALTs" Stanford" ></\> 

<k KKEI‘="http: //wwir-cs. stanford.edu/"> 

<Itt& SBC« "/gifs /logo. csd. gif" ALT«"CS dept"x/A> 

<A KREF*"http: //wwir*-pcd. stanford.edu/"> 

<HHj SBC* "/gifs /logo. pod. gif ’ ALTs"PCD grp"x/A> 
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When including images, it is good manners to always use <ALT="text description of the 
graphic"> to orient readers who are using browsers that can't display images. 

Images are treated as large letters-sur rounding text can be aligned next to the image 
but it is important to include a special alignment (Img align=left) and line break 
command to clear the image and move to the next available space (br=clear left). 
Otherwise text and images will not align properly next to an image. An example 
drawn from Highland Graphics 

(http://www.itsnet.com/home/highland/raytrace.html) illustrates the principle 
(Hgure 2). 

Figure 2. HTML script an -1 associated screen display which aligns text next to 
graphics. 

<B>Click on the small image to view a large version.</BxP> 

<A href="fracb.ils.gif'xlmg align=left Img width=128 height=96 src="s- 
fracba.gif>Frat.tal Balls</a> - The 

fractals were created with Fractint then mapped onto the spheres in 3d Studio. 



<BR clear=left> 

<A href="mobius01.gif> 

<Img align=left Img width=128 height=96 src="s-mous01.gif>Mobius l</a> 
- The shape was created in the 3d Studio shaper program, 
saved as a 3ds file, converted to Povray then raytraced in Povray. 
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iPMI NeUcape: Highland Graphics - Raytraclngl BlBIi 
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Highland Graphics - Raytracing ! 



Nevs iiAAc«^ iddeO as of July 21 , 1995. 

Besides cUpert ve also play azound vith compuier (ewiated images. 
Uslnc both Raytxadnc and Rendeiinc softvaze youcancieate lather 
zeahstk: lookinc iina(es. Feel free to dovnload ^se and use them as 
bacX(iound in^es. Commexciali^se of ^se iinac^ ^ cotaDoved 
vithout vzittBn consent from Hi(hland Graphics. 

For more information about rayttarinc, lenderinc or Povray check out 
one of these links; 

The RayTYiclnc Home Pa ge in the UK. 

Or check out the POVRAY OFHCtAL FTP SOE . 

Click om tka smsU isaca to Titir a larca vatsion. 

Fractri Balls • The fnctals veie created 
vith Fractint dien mapped onto die spheres 
tnSdStgdio. 



Moblos 1 * The shape vis created in die 
3d StCHlio shaper program, saved as a 3ds 
fik, converted to Povray then raytraced in 
Povray. 




Paegmtnt: Done 



A persistent problem when using graphics is the size of picture files. There are two 
ways to reduce the size of picture files; 

1. reduce the size of the image; or 

2. reduce the number of colours (bit depth) when creating the files. 

GIF files are restricted to 8 bit (256) colours. JPEG images can be used for greater bit 
depths, andl6 bit (thousands) and 32 bit (millions) colours are typical. Adjustments to 
either of these variables will affect the quality of the image when it is displayed on 
screen. Whether or not the quality difference is perceived, and whether the 
increased file size and loading time is worth the concomitant increase in perceived 
image quality is often a difficult judgement to make. We were unable to find any 
research which directly addressed these questions, so we designed an experiment to 
determine the actual costs and perceived quality differences when the size and bit 
depth of an image are manipulated. 

Research Questions: 

How will larger and smaller pictures compare in file size, loading time and perceived 
image quality? 

How will altering the bit depth of images influence their file size and perceived 
quality? 



Subjects: 




Designing Multimedia for HTML 



8 



Fifteen graduate students and senior undergraduate students studying educational 
technology, and seventeen adult employees at the University of Saskatchewan 
volunteered to participate in the study. 

Treatment: 

To measure perceived image quality, a full-colour 5” x7” portrait was scanned on an 
Apple II Colour Scanner at the highest quality settings. The resulting file was 
imported into Adobe Photoshop to create six versions of the photograph, including 
two image sizes (640 x 480 pixels) and three colour quality settings (32 bit, 16 bit, and 
8 bit). Each was saved first as a PICT file, and subsequently as a JPEG and GIF file 
without any type of compression algorithm. Each image was imported into a program 
created with Authorw'are Professional v. 2.2, and a series of “pages” created to 
provide a paired comparison of every possible combination of inx,.;ge variables. The 
order of comparison was constructed according to recommendations by Ross (1934) 
for conducting paired comparisons to eliminate effects of picture location and 
presentation order. A Thurstone Scale was constructed for comparing resultant data 
(Torgerson, 1958). 

GIF files were created by converting the PICT files using Photoshop v.2.5.1. PICT file 
colours were indexed at 8 bit colour (256 colours), and saved in the CompuServe GIF 
format. HTML image file formats require 8 bit colour indexing. This means that the 
quality comparisons of picture files with 16 or 32 bit depth colour will only matter to 
multimedia development projects using JPEG files and a helper application for 
viewing. 

The treatment was administered on two matched Power Macintosh 8100/80AV 
computers running under System 7.5, with 17" Apple MultiScan monitors. The 
computer desktops were matched for background (middle grey) and extraneous 
windows and desktop icons were removed. 

Each subject completed the treatment individually and without consultation. Subjects 
were asked to compare pairs of images as they appeared on the screen, and judge 
which image had the higher quality. Selections were made by clicking on buttons 
beneath each image (see Figure 3). 

Figure 3. Screen sample from the image quality experimental treatment. 
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Select thi^ Mcture you think has the higher quality by clicking on Its button. 




[ This one ] 



Results: 

The paired comparisons data were used to construct a Thurstone scale. Figure 4 is a 
graphic display of the Thurstone scale points. One of the advantages of Thurstone 
scaling is that it provides a method for representing distances meaningfully. 
Graphically, it is easy to describe the relative positions of the quality ratings. The 
rank order of Thurstone scale points is presented in Table 1 (l=highest quality 
rating, 6=lowest quality rating). 

File sizes of the image files were obtained from the “Get Information” system 
function on Macintosh System 7.5. 

Loading times were obtained by creating separate HTML documents for each GIF 
image with no other information in the document. A home page was created with 
links to the picture documents, and all of the documents were housed in a single 
folder on the computer’s hard drive. Loading times were measured with a stopwatch 
from the time the mouse was clicked on the link in the home page until the complete 
document appeared. 

Table 1. File size and loading time and quality rating for different size imr.ges and 
different bit depths. 



Image 


File Size (Kb) 


Loading Time 


Thurstone 


Thurstone 




(seconds) 


Scale Point 


Scale 

Ranking 
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648x463 (32 bit- 
JPEG) 


442 


9 


4.24 


1 


320x 229 (32 bit- 
JPEG) 


215 


4 


0.00 


5 (tie) 


648 x 463 (16 bit- 
JPEG) 


476 


9 


3.39 


3 


320 x229 (16bit- 
JPEG) 


215 


4 


3.81 


2 


648 X 463 (8 bit-GIF) 


553 


4.5 


2.43 


4 


320 X 229 (8 bit-GIF) 


68 


2 


0.00 


5 (tie) 



Figure 4. Graphic representation of Thurstone scale points for images; 
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The loading times for pictures from the hard drive of the computer suggested 
that higher quality images (either 16 or 32 bit colour depth) can be achieved 
by approximately doubling the loading time needed for an 8 bit image. This 
may not appear to be a high cost to the developer until one remembers that 
these images and documents were loaded directly from the hard drive of the 
computer. No network or telephone lines were involved, thereby rendering a 
very optimistic data set. Slower transmission rates over various carriers would 
also double for higher quality, images, and the slower the carrier, the more 
aggravating the result for the user. 

Generally speaking the Thurstone scale suggests that for larger pictures, extra 
colour depth is desirable, but it is of little consequence with smaller pictures. 
On the whole, the group preferred large pictures, with the smaller 16 bit 
image providing an interesting anomaly. When larger versions were 
compared, the bit depth was picked out, and subjects rated the quality of the 
images in ascending order, from lowest to highest bit depth of colour. 

Not so for smaller pictures. Bit depth of colour seemed to have little to do with 
the quality ratings given the pictures. The similar low ratings of smaller 8 and 
32 bit pictures could indicate that the two images are inseparable visually. This 
is not likely, however, given that the smaller 16 bit picture had a higher 
quality rating than the other two smaller pictures. It may be that there is an 
optimal colour depth for different size images, one which takes maximum 
advantage of the colours available. It could also be that picture size is so 
influential that the companion variable (bit depth of colour) is virtually 
ignored. This deserves further study. 
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Movie Use and Display 

Our best advice is to avoid using movies at almost any cost, unless of course the movie 
is an essential part of the instructional material, and the material can’t be depicted 
any other way. At the present time and under almost every conditicm, digital movies 
are poor in quality. When downloaded from a web site, movies require companion 
programs to run (tlius frustrating many users), and they are agonizingly slow to 
execute (further frustrating users). At the very least, whenever you must use movies, 
sound and larger image files, allow the user the option to link to the files rather than 
open them automatically on the page. As part of Ae link, warn the user of the size of 
the file. It is also courteous to use thumbnail sketches in the home documents and 
link them to larger versions if the smaller image can give the user an idea of the 
content of the larger file. 

Also remember that helper applications (viewer applications) are required by most 
browsers to play sound files and movies. Notify users of file types to discourage time 
consuming and futile down-loads. 

There are two ways to reduce the size of movie files: 

1. reduce the size of the movie window; or 

2. reduce the number of frames/second of the recording. 

Movies can be recorded in various sizes, including quarter, half and full screens. 

They can also be recorded at any number of frames per second up to 30 frames per 
second, which is the standard rate for NTSC video playback. Each frame of video 
requires additional file space, so the greater the number of frames per second, the 
greater the resulting file size. But there is a further complication. Unless fairly 
sophisticated, high-end production software and hardware is used, computers cannot 
record 30 frames per second. Indeed, even if recorded, few computers are capable of 
playing back larger video windows at 30 frames per second. 

Af'justments to either of these variables (window size, frames per second) may also 
reduce the perceived quality of the image when it is displayed on screen. As with the 
question of image quality we were unable to find any research which addressed these 
questions, so we designed an experiment to determine the actual costs and perceived 
quality differences when the window size and frames per second of a digital movie 
are manipulated. 

Research Questions: 

How will larger and smaller movie windows compare in file size, loading time and 
perceived image quality? 

How will recording digital movies at different frames per second influence their file 
size, loading time and perceived quality? 

Subjects: 

Fifteen graduate students and senior undergraduate students studying educational 
technology, and seventeen adult employees at the University of Saskatchewan 
volunteered to participate in the study. 

Treatment: 

To measure perceived image quality, six versions of a 30 second clip of video were 
digitized as QuickTime movies. The original video was recorded on a Sony Betacam and 
transferred to videodisc. A segment was chosen which had few colours (to reduce 
possible contamination from this variable) but a great deal of detail and almost 
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continuous motion. The digi'.al versions were recorded in two window sizes (quarter 
and half) and three settings of frames per second (30, 15 and 10) without key frames 
or audio using Apple’s FusionRecorder 1.0.2 with a Power Macintosh 6100 with 16 Mb 
of RAM and 2 Mb of VRAM. Each movie file was imported into a program created with 
Authorware Professional v. 2.2, and a series of “pages” were created to provide a 
paired contparison of every possible combination of movie variables under study. The 
order of comparison was constructed according to recommendations by Ross (1934) 
for conducting paired comparisons to eliminate effects of picture location and 
presentation order. A Thurstone Scale was constructed for comparing resultant data 
(Torgerson, 1958). 

The treatment was administered on two matched Power Macintosh 8 100/ 80 AV 
computers running under System 7.5, with 17" Apple MultiScan monitors. The 
computer desktops were matched for background (middle grey) and extraneous 
windows and desktop icons were removed. 

Each subject completed the treatment individually and without consultation. Subjects 
were asked to compare pairs of movies as they appeared on the screen, and judge 
which movies had the higher quality. The movies played continuously until a 
selection was made. Selections were made by clicking on buttons beneath each movie 
(see Figure 5). 

Figure 5. Screen sample from the movie quality experimental treatment. 



Select the uideo you think has the higher quality by clicking oh its button. 




Results: 

The paired comparisons data were used to construct a Thurstone scale. Figure 6 is a 
graphic display of the Thurstone scale points for the digital video. The rank order of 
Thurstone scale points is presented in Table 2 (l=highest quality rating, 6=lowest 
quality rating). 
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File sizes of the image files were obtained from the “Get Information” system 
function on Macintosh System 7.5. To load movies in HTML documents, they must first 
be “flattened.” Adobe Premier, a video editing program for the Macintosh, was used to 
flatten the QuickTime movies. 

Loading times were obtained by creaiing a home page with links to the movie 
documents, and all of the documents were housed in a single folder on the computer’s 
hard drive. Loading times were measured with a stopwatch from the time the mouse 
was clicked on the link in the home page until the movie appeared. 



Table 2. File size, loading time, playback rate and quality rating for QuickTime 
movies. 



Window Size 
and FPS 


Original 
Movie Size 
(Mb) 


Average 

Loading 

Rate 

(seconds/ 

Mb) 


Total 

Loading 

Time 

(min:sec) 


Thurstone 

Scale 

Point 


Image 

Qjiality 

Ranking 


Quarter (30fps) 


9.3 


43.3 


6:40 


0.00 


6 


Half (30fps) 


32.8 


42.2 


23.10 


0.27 


2 (tie) 


Quarter (15fps) 


4.5 


45.7 


3.26 


0.24 


5 


Half (15fps) 


16.9 


42.3 


11:54 


0.25 


4 


Quarter (lOfps) 


3.2 


46.2 


2:28 


0.27 


2 (tie) 


Half (lOfps) 


11.9 


44.5 


8:50 


0.36 


1 



Figure 6. Graphic display of Thurstone scale points for digital video. 
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The most dramatic data are the loading times for video. Loading times ranged from 2.5 
minutes to more than 23 minutes, depending on file size. Few users will Wciit 23 
seconds for a movie, much less 23 minutes. For video to be a viable instructional 
option with HTML, loading times must improve exponentially. 

It appears that the size of the video window is more important than frame speed 
(Figure 6). Subjects, on the whole, preferred the larger images, and an interesting 
correlation with frames per second may be indicated by the data. For smaller video 
segments, there was an inverse relationship between frames per second and the 
quality rating. A similar, but less perfect relationship was found with larger video 
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images. The computers used in this instance were not able to process 30 frames per 
second— something less than that was actually displayed. They were, however able to 
process 10 frames per second. We speculate that the resultant similarity between the 
recording rate and playback rate may result in a smoother appearance to the 
displayed video. This is worthy of additional research. 



Summary 

HTML was specifically designed to distribute hypermedia on the World Wide 
Web, and it does so--within limits. We urge would-be developers of multimedia 
who are contemplating using the WWW to keep in mind some of the factors 
dhcussed in this paper, and to proceed with only those projects that are viable 
despite current limitations of hardware (both in the distribution technology 
and on the desktops of learners). While richly-colored graphics and video emit 
a siren call to developers, developers must keep in mind the potential "wait 
times" they may inadvertently inflict upon learners, most of whose equipment 
will not likely have the computational horsepower of the machines on which 
development took place. The limited bandwidth of most carriers and the slower 
speed of many computers makes the use of multimedia on the WWW awkward 
and of questionable worth. Still, technology will continue to improve, and 
given the enormous popularity of the internet for sharing information, it is 
likely that its capacity for dealing with multimedia will improve dramatically. 

Even when contemplating using HTML as the basic tool for CD-ROM 
development (e.g., see Misanchuk and Schwier, 1996), developers should be 
circumspect in their use of graphics and, especially, video. The pilot studies 
reported here lead one to believe that quality (in the eyes of the learner) may 
not always be reflective of technical superiority. Despite the fact that small 32 
bit still pictures were ranked lowest in quality, right along with small 8 bit 
pictures, and that 30 fps quarter-size video ranked lowest in quality while 10 
fps half-size ranked highest, size alone is probably not the answer (since 
small 16 bit pictures ranked between large 16 bit and large 32 bit ones). Clearly 
more investigation is needed before robust guidelines can be formulated to 
help designers choose optimal (as opposed to maximal) size, colour depth, and 
frame rates. For the moment, file size and the initial findings reported here 
can be used as guides, but we caution that the studies need to be replicated with 
multiple stimuli of a demonstrably more instructional nature. 

At present, we suggest that the limitations of HTML on the WWW as a 
multimedia architecture largely argue against its use for interactive 
multimedia projects. However, along with most developers on the World Wide 
Web, we eagerly anticipate improvements which will make the internet viable 
for delivering interactive multimedia. 
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Appendix 1 

Addresses to clip art and icon collections on the World Wide 

Web 

-- http://www.dorsai.org/~ackerman/clip.html 
-- http://www.wellesley.edu/Gifs/ 

-- http://pauillac.inria.fr/~lang/hotlist/clipart/ 

-- http://thorplus.lib.purdue.edu/~carl/IconBib.html 
-- http://barrow.uwaterloo.ca/~ghballin/wedpage.html 
-- http://www-c8.lanl.gov/icons/main.html 

- http://www.cs.yale.edu/homes/sjl/clipart.html 

~ http://www.itec.sfsu.edu/multimedia/Clip-art.html 

- http://www-c8.lanl.gov/icons/nian.html 

- http://pasture.ecn.purdue.edu/~staleyr/www.html 
" http://pasture.ecn.purdue.edu/~staleyr/www.html 

- http://www.emf.net/~troop24/icons/clipart.html 

- http://miso.wwa.com/~boba/images.html 

- http://www.monash.edu.au/alst6/com/nate/WWW/corelclipart.html 

- http://web66.coled.umn.edu/Share/Share.html 

- http://www.ocf.org/OrthodoxPag/icons/icons.html 

- http://users.aol.eom/newblossom/SC.Catalog.html 

- http://www.mordor.com/ellison/desktop.html 
~ http://baste.magibox.net/~jhaley/ 

- http://www.adobe.com/imageclub/html/info/info-index.html 

- http://dutera.et.tudelft.nl/people/vdham/info-mac/IM146-13.html 

- http://www.mindspring.com/~guild/graphics/graphics.html 

- http://www.iohk.com/sensa.html 

- http://quasar.fastlane.net/homepages/britton/ 

~ http://www.zia.com/educate.htm 

- http://www.adobe.com/imageclub/html/new/new-index.html 

~ http://www2.ncsu.edu/bae/people/faculty/walker/hotlist/icons.html 

- http://www.mordor.com/ellison/business.html 

- http://www.interlog.com/~rdg/ 

- http://www.cdarchive.com/big_group_of_files_number_ 1 /09 A.htm 
“ http://osiris.colorado.edu/~brumbaug/graphics.html 

~ http://asrt.cad.gatech.edu/home/develop.html 

- http://www.mcli.dist.maricopa.edu/info.html 

- http://mtmisl.mis.semi.harris.com/new_mtop.html 

- http://galen.med.virginia.edu/~baj7d/BaDge77.html 
~ http://www.primenet.com/~accord/computng.html 

- http://www.ies.luth.se/~tim/ 

- http://www.tezcat.com/~sstrong/ 

- http://esu3.esu3.kl 2.ne.us/curriculum/ resourcepage.html 

- http://www.xmission.com/~pengar/homeboys/links.html 

- http://rintintin.colorado.edu/~chrisw/wwwftp.htm 

- http://www.iquest.net/dewpoint/pricing.html 

“ http://www.zdnet.com/~macuser/mu_l 195/reviews/authorware.html 

- http://www.northcoast.com/savetz/pd/pd.html 

- http://www-genome.wi.mit.edu/WWW/resource_guide.html 

- http://dutera.et.tudelft.nl/people/vdham/info-mac/lMtl46-l 3.html 
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